Many computer operating systems support a principal identity. This identity is highly privileged and may perform any operation on the local computer system. For example, an administrator program in the UNIX operating system, called ‘Root’ has a high privilege. This program can perform all administrative functions and may bypass any local computer system security. In some computing environments, this single unrestricted concept of system privilege is undesirable, and instead it is necessary to have a finer grained model security system. One approach to accomplishing this is to add an external security manager on top of the operating system, which applies additional rules for controlling access to system functions and resources.
External security managers can be created that augment standard UNIX security in the native operating system. These security managers support the definition of fine-grained rich security policy including more control over the privilege granted to the system administration program. Usually, the security manager maintains enhanced external user definitions. These user definitions contain extended information such as user group membership or roles. The security manager re-maps the local system user to its external user on resource accesses in order to make authorization decisions.
One problem with the implementation of a security manager is establishing a model in order to apply the security manager to a computing system and then prevent the normal OS administrative user from potentially disabling or administering the external manager without the required privilege. In addition, the security manager needs to be administered by a designated user, which has full administrative privilege to the external security manager, but limited capabilities with respect to the native operating system.
One of the functions of such a security administrator would be to restrict the actions and capabilities of the native system privileged user. A security manager might achieve this by intervening in accesses to system resources after it is made active on the system. It is likely that the native system administrative privilege is required to initially make the external security manager active. However, once the external security manager becomes active, it would be desirable to prohibit the native administrative user from being able to disable the external security manager. In addition, the external manager should not necessarily gain access to compromise the existing security of the native system.
There remains a need for a technique that would allow a native system administrator a broad privilege when activating an external security manager; transferring the privilege with respect to the activated security manager to a security administrator; and from the native system administrator such that the native system administrator has no privilege to the security manager.